@stuartmorgan-g you might know - how do you deal with dart sdk breaking changes that affect this repo?

This repo uses dart sdk from flutter, landing new dart sdk into flutter is impossible because the roll breaks these flutter packages, but then updating fluttter packages and rolling updated flutter packages together with roll of dart sdk is impossible because flutter packages uses old dart sdk(from flutter) so updating PR(like this one) fails.

how do you deal with dart sdk breaking changes that affect this repo?

Usually we don't; I'm having a hard time remembering a case where the Dart SDK broke us with a change that wasn't in a major Dart version.

There are a few problems, which have different solutions:

1. The flutter tool actually uses this package, so there's a true circular dependency. This is bad, and I'm in the process of standing up flutter/core-packages precisely to fix issues like that (this package is slated to be moved as soon as I have the CI set up there). Luckily we can ignore this problem here since this is test-only.
2. The analyzer run in flutter/flutter blocking the Dart->flutter/flutter roll can be addressed by temporarily making that test in flutter/flutter non-blocking to temporarily break that artificial cycle in our test infra. However, that will just kick the can down the road to:
3. Once the roll lands in flutter/flutter, the flutter/flutter->flutter/packages roll will be blocked, because we analyze our packages on both stable and main.

We'll need a solution to 3, so if we can solve it in a way that fixes 2 we can avoid having to turn tests off and on in flutter/flutter.

I haven't dug into the exact details here; could we do something slightly gross with dynamic to make this compile for both versions? If not, given the limited scope in this particular instance I think my preference would be to just comment out this test, with a tracking issue to turn it back on once this breaking change reaches stable.

I haven't dug into the exact details here; could we do something slightly gross with dynamic to make this compile for both versions? If not, given the limited scope in this particular instance I think my preference would be to just comment out this test, with a tracking issue to turn it back on once this breaking change reaches stable.

thank you Stuart. I commented out the test with actual changes as comments so this can be uncommented and test restored as soon as dart sdk lands in flutter.

Too late for this PR obviously, but in the future if something like this is necessary please put the issue link directly in the code as a comment so that it's trivial for someone to map from the weird commented out code to the tracking issue without having to dig through git blame.

so this can be uncommented and test restored as soon as dart sdk lands in flutter.

Again, it's not as soon as it lands, it's when it reaches the stable channel of Flutter. For something landing in main right now, we expect that to be in August. The file will be in this state for months, not a day or two.

Again, it's not as soon as it lands, it's when it reaches the stable channel of Flutter. For something landing in main right now, we expect that to be in August. The file will be in this state for months, not a day or two.

I missed that. What is the reason to wait for stable?

because we analyze our packages on both stable and main.

Sounds like a pretty limiting requirement. Is that because there is only one channel no branches of flutter packages available?

What is the reason to wait for stable?

I don't think I'm following; the next line of your comment is a quote that would be my answer, which makes me think I'm not understanding what the question actually is here.

because we analyze our packages on both stable and main.

Sounds like a pretty limiting requirement.

In practice I consider it to have been extremely successful in accomplishing the desired goal (ensuring that fixes can get out quickly to the customers using a stable version of Flutter rather than main, which is pretty close to all of them) with minimal effort.

It has also had the unintended but useful secondary effect of making it more obvious to people working in flutter/flutter why we generally want to avoid hard breaking changes in favor of phased migrations. So to the extent that this has been limiting in practice, I think it's mostly been a positive rather than a negative.

Is that because there is only one channel no branches of flutter packages available?

If I'm understanding this question correctly, yes, this policy would not be necessary if we maintained release branches and a branch management process with cherry picks for all of our packages.

So far, in the years we've had this policy, I haven't seen evidence that the eng cost of that overhead would give nearly enough value to be worthwhile.

What is the reason to wait for stable?

I don't think I'm following; the next line of your comment is a quote that would be my answer, which makes me think I'm not understanding what the question actually is here.

Basically, I wanted to confirm my understanding. Besides running analysis(which is what was quoted) I think you also actually run the tests both on stable and on main ensuring that that like you said that flutter/packages is fully compatible with stable.

because we analyze our packages on both stable and main.

Sounds like a pretty limiting requirement.

In practice I consider it to have been extremely successful in accomplishing the desired goal (ensuring that fixes can get out quickly to the customers using a stable version of Flutter rather than main, which is pretty close to all of them) with minimal effort.
It has also had the unintended but useful secondary effect of making it more obvious to people working in flutter/flutter why we generally want to avoid hard breaking changes in favor of phased migrations. So to the extent that this has been limiting in practice, I think it's mostly been a positive rather than a negative.

Is that because there is only one channel no branches of flutter packages available?

If I'm understanding this question correctly, yes, this policy would not be necessary if we maintained release branches and a branch management process with cherry picks for all of our packages.
So far, in the years we've had this policy, I haven't seen evidence that the eng cost of that overhead would give nearly enough value to be worthwhile.

By "limiting" I meant that you are not able to use features in dart/flutter until they are released in stable creating this many-months feedback delay. I think it would have been valuable to get that flutter/packages team's feedback sooner.

By "limiting" I meant that you are not able to use features in dart/flutter until they are released in stable

The alternatives are:

1. we constantly maintain two branches of every package, where one branch supports stable, and we cherry-pick essentially everything between branches, including maintaining diverging copies where the new features cause code differences, or
2. features and bug fixes to packages are routinely delayed for multiple months in getting to clients.

As I said above, I haven't seen any evidence that (1) would be worth the effort. (2) seems like a significant net loss to me.

creating this many-months feedback delay. I think it would have been valuable to get that flutter/packages team's feedback sooner.

Could you point me to some examples of where this has been as issue? I'm not sure why landing changes on main would be necessary for trying something out and providing feedback.

Could you point me to some examples of where this has been as issue? I'm not sure why landing changes on main would be necessary for trying something out and providing feedback.

Isn't this introduction of InterfaceAddress class with its support for broadcast address be something that flutter/packages are not able to use until several months in the future?

Sorry, I'm not following. What valuable feedback would landing 948cc4a have provided that is being delayed?

Sorry, I'm not following. What valuable feedback would landing 948cc4a have provided that is being delayed?

I'm thinking of a potential feedback where some flutter/packages's use of InterfaceAddress revealed some crashes or other unexpected behaviors resulting from original change that would require fixes in dart sdk.

It's what I think that normally is described as "eating your own dog food" kind of thing.

I'm thinking of a potential feedback where some flutter/packages's use of InterfaceAddress revealed some crashes or other unexpected behaviors resulting from original change that would require fixes in dart sdk.

Anyone is welcome to open a draft PR with those changes as soon as it rolls through main to this repo (usually a day or two delay from flutter/flutter); our presubmit and postsubmit tests are pretty much identical, so just putting up the PR should give all of that information.